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Abstract 


The IETF Standards Process requires that all normative references for 
a document be at the same or higher level of standardization. RFC 
2026 section 9.1 allows the IESG to grant a variance to the standard 
practices of the IETF. This document explains why the IESG is 
considering doing so for the revised version of the BGP-4 
specification, which refers normatively to RFC 2385, "Protection of 
BGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain 
at the Proposed Standard level. 


1. Introduction 


The IETF Standards Process [RFC2026] requires that all normative 
references for a document be at the same or higher level of 
standardization. RFC 2026 section 9.1 allows the IESG to grant a 
variance to the standard practices of the IETF. Pursuant to that, it 
is considering publishing the updated BGP-4 specification [RFC4271] 
as Draft Standard, despite the normative reference to [RFC2385], 
"Protection of BGP Sessions via the TCP MD5 Signature Option". RFC 
2385 will remain a Proposed Standard. (Note that although the title 
of [RFC2385] includes the word "Signature", the technology described 
in it is commonly known as a Message Authentication Code or MAC, and 
should not be confused with digital signature technologies.) 


[RFC2385], which is widely implemented, is the only transmission 


security mechanism defined for BGP-4. Other possible mechanisms, 
such as IPsec [RFC2401] and TLS [RFC2246], are rarely, if ever, used 
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for this purpose. Given the long-standing requirement for security 
features in protocols, it is not possible to advance BGP-4 without a 
mandated security mechanism. 


The conflict of maturity levels between specifications would normally 
be resolved by advancing the specification being referred to along 
the standards track, to the level of maturity that the referring 
specification needs to achieve. However, in the particular case 
considered here, the IESG believes that [RFC2385], though adequate 
for BGP deployments at this moment, is not strong enough for general 
use, and thus should not be progressed along the standards track. In 
this situation, the IESG believes that variance procedure should be 
used to allow the updated BGP-4 specification to be published as 
Draft Standard. 


The following sections of the document give detailed explanations of 
the statements above. 


2. Draft Standard Requirements 


The requirements for Proposed Standards and Draft Standards are given 
in [RFC2026]. For Proposed Standards, [RFC2026] warns that: 


Implementors should treat Proposed Standards as immature 
specifications. It is desirable to implement them in order to 
gain experience and to validate, test, and clarify the 
specification. However, since the content of Proposed Standards 
may be changed if problems are found or better solutions are 
identified, deploying implementations of such standards into a 
disruption-sensitive environment is not recommended. 


In other words, it is considered reasonable for flaws to be 
discovered in Proposed Standards. 


The requirements for Draft Standards are higher: 
A Draft Standard must be well-understood and known to be quite 
stable, both in its semantics and as a basis for developing an 


implementation. 


In other words, any document that has known deficiencies should not 
be promoted to Draft Standard. 
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3. The TCP MD5 Signature Option 


[RFC2385], despite its 1998 publication date, describes a Message 
Authentication Code (MAC) that is considerably older. It utilizes a 
technique known as a "keyed hash function", using MD5 [RFC1321] as 
the hash function. When the original code was developed, this was 
believed to be a reasonable technique, especially if the key was 
appended (rather than prepended) to the data being protected. But 
cryptographic hash functions were never intended for use as MACs, and 
later cryptanalytic results showed that the construct was not as 
strong as originally believed [PV1, PV2]. Worse yet, the underlying 
hash function, MD5, has shown signs of weakness [Dobbertin, Wang]. 
Accordingly, the IETF community has adopted Hashed Message 
Authentication Code (HMAC) [RFC2104], a scheme with provable security 
properties, as its standard MAC. 


Beyond that, [RFC2385] does not include any sort of key management 
technique. Common practice is to use a password as a shared secret 
between pairs of sites, but this is not a good idea [RFC3562]. 


Other problems are documented in [RFC2385] itself, including the lack 
of a type code or version number, and the inability of systems using 
this scheme to accept certain TCP resets. 


Despite the widespread deployment of [RFC2385] in BGP deployments, 
the IESG has thus concluded that it is not appropriate for use in 
other contexts. [RFC2385] is not suitable for advancement to Draft 
Standard. 


4. Usage Patterns for RFC 2385 


Given the above analysis, it is reasonable to ask why [RFC2385] is 
still used for BGP. The answer lies in the deployment patterns 
peculiar to BGP. 


BGP connections inherently tend to travel over short paths. Indeed, 
most external BGP links are one hop. Although internal BGP sessions 
are usually multi-hop, the links involved are generally inhabited 
only by routers rather than general-purpose computers; general- 
purpose computers are easier for attackers to use as TCP hijacking 
tools [Joncheray]. 


Also, BGP peering associations tend to be long-lived and static. By 
contrast, many other security situations are more dynamic. 


This is not to say that such attacks cannot happen. (If they 


couldn’t happen at all, there would be no point to any security 
measures.) Attackers could divert links at layers 1 or 2, or they 


Bellovin & Zinin Informational [Page 3] 


RFC 4278 Standards Maturity Variance: RFC 2385 and BGP-4 January 2006 


could (in some situations) use Address Resolution Protocol (ARP) 
spoofing at Ethernet-based exchange points. Still, on balance, BGP 
is employed in an environment that is less susceptible to this sort 
of attack. 


There is another class of attack against which BGP is extremely 


vulnerable: false route advertisements from more than one autonomous 
system (AS) hop away. However, neither [RFC2385] nor any other 
transmission security mechanism can block such attacks. Rather, a 


scheme such as S-BGP [Kent] would be needed. 
5% LDP 


The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385]. 
Deployment practices for LDP are very similar to those of BGP: LDP 
connections are usually confined within a single autonomous system 
and most frequently span a single link between two routers. This 
makes the LDP threat environment very similar to BGP’s. Given this, 
and a considerable installed base of LDP in service provider 
networks, we are not deprecating [RFC2385] for use with LDP. 


6. Security Considerations 


The IESG believes that the variance described here will not adversely 
affect the security of the Internet. 


7. Conclusions 


Given the above analysis, the IESG is persuaded that waiving the 
prerequisite requirement is the appropriate thing to do. [RFC2385] 
is clearly not suitable for Draft Standard. Other existing 
mechanisms, such as IPsec, would do its job better. However, given 
the current operational practices in service provider networks at the 
moment -- and in particular the common use of long-lived standard 
keys, [RFC3562] notwithstanding -- the marginal benefit of such 
schemes in this situation would be low, and not worth the transition 
effort. We would prefer to wait for a security mechanism tailored to 
the major threat environment for BGP. 
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